1. Field of the Invention
The present invention relates to the certification of data sent over a network, more specifically over an insecure network such as the Internet by cryptographic means.
Whenever information is transmitted across an insecure network, there is the possibility that this may be intercepted and interfered with in some way. Therefore, many activities carried out using such a network to connect the parties involved in the activity require each party to confirm the identity of the other party(s). This is particularly the case with activities conducted over the Internet.
One way of meeting the above requirement is to use a digital signature. The origin of data sent across an insecure network can be authenticated using such a digital signature.
Such a signature fulfils the roles of a traditional signature: to provide authentication of origin, and may also have legal significance. It is therefore important to ensure that it is difficult, if not impossible, to sign an electronic document fraudulently, in order to suggest an incorrect point of origin.
A generally accepted—and the only known—way of achieving this is to use cryptography. In particular, a form of asymmetric cryptography called a public key scheme is used. A public key scheme employs two different but mathematically related “keys”. Such asymmetric keys work by using a so-called “one way” algorithm. Such an algorithm can be used to produce a so-called digital signature with one key and verify this with the other key, but it is very time-consuming and in fact practically infeasible, with the right choice of key size, to use the verifying key to generate the signature. Currently it is a very simple matter to use the verification key to verify the signature and hence the integrity and origin of the message, and this is how each key pair is normally used. These public key schemes may either be based on so called one-way functions, where the verification process involves checking a mathematical equation (e.g. ElGamal, elliptic curves, etc. see Menezes, A., Oorschot, P. van, and Vanstone, S., Handbook of Applied Cryptography, CRC, 1996, the contents of which are incorporated herein by reference) or on encryption-decryption functions (e.g. RSA, see Rivest, R. L., Shamir, A. and Adleman, L, A method for Obtaining Digital Signatures of Public Key Cryptosystems, Communications of the ACM, 21 (2), 1978: 120-126, the contents of which are incorporated herein by reference). The latter differs from symmetric encryption, where the same key is used to both encrypt and decrypt a message. One of the advantages of such asymmetric methods is that even if a third party is in possession of the key used to verify the message they cannot produce the signature without the other key. If an encryption-decryption scheme is used, the encryption key is the verifying key and the decryption key is the signing key.
The most widely used public scheme, RSA, makes use of two very large prime numbers, and the fact that, at the time of writing, it takes a very long time to factor the product of these two primes back into the two original numbers. With sufficiently large numbers, RSA can therefore be highly resistant to signature falsification. Generally, one of the keys is the product n of the two prime factors pa and q and a so-called public exponent e, and the other is a number derived from the pair of primes and e using modular arithmetic. The public exponent e must be chosen as mutually prime to p−1 and q−1, and a secret exponent d may then be derived e.g. as the smallest positive integer satisfying ed−x(p−1)(q−1)=1 for some x using Euclid's algorithm repeatedly. Further information on this may be found in Menezes et al, mentioned above.
Because knowledge of the key used for verification does not enable signing, it is possible to broadcast this key (the so called “public key”) as widely as possible, to as many people as possible, typically by providing a so-called Public Key Infrastructure (PKI, see CCITT (Consultative Comm. on Intern. Telegraphy and Telephony), Recommendation X.509: The Directory—Authentication Framework, 1994, and Public Key Infrastructure: The PKIX Reference Implementation, Internet Task Engineering Force, both of which are incorporated herein by reference) so that anyone can make use of it.
If a particular public key can be used to verify a message, this shows that the originator of the message must have been the user holding the private key. It is therefore possible to indicate the origin of a particular message by making use of public key schemes.
However, this therefore requires that there is some scheme in place to bind the identity of the user to a particular public key pair
For example, the holder could simply announce that he owns the public/private key pair to the world. However, the recipient of the signed document would then only have the word of the holder as to his identity and that the holder is the owner, and that the key has not been compromised. In this case, the recipient of the message cannot verify that the sender of the message is being truthful about their identity or ownership status, only that the message has come from someone claiming a particular identity and claiming to be the owner of the key pair.
Because of the above problems of verification of the identity and status of PKI key owners, third parties called Certification Authorities (CAs) have evolved to certify that a particular user is who they claim to be. The user must supply certain credentials to the. CA and his public key, and the CA in return issues a so-called certificate, which is nothing but a signature generated by the CA on a message in a chosen format, such as X.509v3, consisting of the user's credentials and his public key. In addition, the CA must make a Directory available, from which the status of any user key can be communicated to any other user at any time, either by use of so-called revocation lists, or by online inquiry. Furthermore, the CA issues a Certificate Policy Statement, which states the rules for the users of the system, including the method by which the users have been identified. For details see CCITT, and Public Key Infrastructure: The PKIX Reference Implementation, mentioned above.
A digital certificate, comprising a public key/private key pair has additional advantages over a traditional signature solution without certificates in that it may have a limited operational period and may also be suspended or revoked, should the private key of the user be compromised, for example by being made available to a third party. In order for the signature to be of any use, it must preferably be represented in a standardised format, such as Public Key Crypto Standard (PKCS#I) signatures, formatted according to CMS (the Cryptographic Message Syntax) (PKCS#7, for further information on which see PKCS #1,7, RSA Cryptography Standard, RSA Laboratories, 2001, the contents of which are incorporated herein by reference).
As can be seen from above, it is vitally important that the private key of a signature be kept secure at all times, otherwise its value is removed, as its value lies in the fact that it certifies the identity of the author of a message by showing that the message originated from the owner of a particular key pair. This is only the case where the private key has not been compromised. Therefore, steps must be taken to maintain the security of the private key.
2. The Prior Art
One established approach to the protection of the private key of a key pair used for digital signatures is to use software solutions and then store it on the owner's workstation or a floppy disk protected by a pincode or passphrase controlled by the owner. However, it is generally agreed that such a software-only solution is not sufficiently secure for high value transactions, unless the workstation is extraordinarily well protected. This is because it will typically be possible to recover the private key using an exhaustive search for the password on the workstation, and in any case, it is difficult to protect the private key from so-called “Trojan horse” attacks. Here a malicious programme, a type of virus, is installed by an intruder, e.g. via an e-mail which contains an executable file, and this programme secretly copies the private key of the user when it is being used in the signature process, or it secretly copies the passphrase used to protect the private key. Measures can be introduced which make such attacks more difficult, but even so, they are still not easily prevented. For security and applicability reasons the physical protection offered by smartcards, which in addition provide a mobile solution, is attractive. The disadvantage of this method is that it requires smartcard readers, which are still not widely available.
An alternative, which for a long time was considered very attractive, is instead to store the private key on a smartcard (chipcard). But this requires that the workstation used for the application must have a smartcard reader attached. As workstations very rarely have such a reader built-in as standard, and as there is no single dominating standard for communicating with the chipcard, the only possibility is to attach an external unit and install a driver on the workstation, which is both time consuming and expensive.
Identification and security are major issues for solutions that allow the user to generate a digital signature. It is therefore an object of this invention to remove or ameliorate at least one of the problems associated with the prior art. In particular, an object is to reach a high security level, while at the same time give a flexible solution to the problem.
In addition, private keys stored on a workstation may appear “in the clear”, that is in a non-encrypted form, in the user's computer's cache or printer cache or spooler, or otherwise on an Internet Service Provider (ISP) cache, even if deleted from the user's computer. In fact, even deleted items can be recovered from a computer using specialised techniques to recover data from hard disk drives etc. Indeed, whenever the private key is used for signature generation, it has to be provided in unprotected form.
Other solutions to the security problem allow the user to download their private key from a central server and generate the signature on the workstation in software. This yields the mobility but it is still vulnerable to attacks if the workstation is insecure, which it typically is unless there are restrictions on which workstations can be used to download the private key.